A cluster tool may consist of one or more plasma-processing chambers (i.e., module) and other components to facilitate substrate processing. Each plasma-processing chamber may have a plurality of transducers (i.e., sensors). Each transducer is able to detect specific process parameter (i.e., condition) of the plasma-processing chamber and/or other components of the tool. Examples of process parameters include, but are not limited to, temperature, pressure, step numbers, and gas flow.
A cluster tool interacts with data owners to collect substrate processing (SP) data as a substrate (i.e., wafer) is processed in a plasma-processing chamber. Substrate processing data refers to two types of data (i.e., meta-data and process data) that may be gathered. Meta-data are individual data items that identify a substrate (i.e., substrate id, lot id, etc.) or a process (i.e., recipe name, etc.). The other type of data, process data, relates to individual data items that pertain to process parameters (i.e., pressure, gas flow, step number, etc.) monitored by a plurality of transducers (i.e., sensors located in a cluster tool).
As discuss herein, data owner relates to a software interface that interacts with a data source to collect data pertaining to a cluster tool and its sub-components. Data source may include, but are not limited to, transducers that detect conditions of the cluster tool or its sub-components. The data gathered by transducers are generally known as process data. Also, data source may relate to pre-stored data (i.e., meta-data) that may include information about a substrate or a process. Data may be collected when changes occur in a plasma-processing chamber or periodically. Changes may include increases/decreases in temperature, pressure, gas flow, etc.
To facilitate discussion, FIG. 1 shows how data flows from a cluster tool to a database. In a cluster tool 102, data is collected by each data owner (104a, 104b, and 104c). The data that is collected by each data owner may be, for example, a name of a data point, absolute timestamps when changes occur, and a value for each absolute timestamp. For example, data owner 104a may be a software interface that interacts with a transducer that detects changes in pressure. Thus, data collected by data owner 104a may include pressure as the name of the data point, absolute timestamps when pressure changes occur, and a pressure value for each absolute timestamp.
Once the data has been gathered, a database interface 106 is notified by data owner (i.e., 104a) via path 108 that data are available for upload. Database interface 106 then sends the data to a database 112 via pipeline 110 to be stored. Database 112 may be located on cluster tool 102 or on a network server. Due to the sheer size of the data that may be collected by cluster tool 102, pipeline 110 may have to be fairly large in order to handle the large bandwidth required to transmit large amount of data to database 112.
The data that is created is stored on individual tables (114a, 114b, and 114c) on database 112. Each table is arranged according to the data owner. For example, table 114a stores information (such as data point, value, and absolute timestamp) gathered by data owner 104a, which monitors pressure changes. One common variable between these tables is absolute timestamp. More details about how absolute timestamps work among the various tables are provided in the discussion about FIG. 2.
FIG. 2 provides examples of tables that may exist in database 112. Each table stores data (i.e., data point, absolute timestamp, and value) about a specific process parameter or meta-data. For example, table 202 stores data about substrate id, table 204 stores data about lot id, table 206 stores data about optical character reader (OCR) id, table 208 stores data about step number, and table 210 stores data about pressure.
Since the data collected is not specific to a substrate, a user may have a difficult time reconstructing processing conditions for a specific substrate when an issue arises. To reconstruct the processing conditions, the user may first have to determine when the substrate entered a plasma-processing chamber. Once the user has the absolute timestamp (i.e., 202a or 202b) at which time the substrate entered the plasma-processing chamber, the user is then able to use that absolute timestamp to compare it against absolute timestamps (i.e., 204a, 204b, 206a, 206b, 208a, 208b, 208c, 208d, 208e, 210a, 210b, 210c, 210d, 210e, 210f, 210g) on the other tables. However, the absolute timestamps on the other tables may not produce a perfect match. A reason for a lack of a perfect match may relate to how data stored on each of the tables is collected when there is a change in a processing parameter.
For example, substrate B enters a plasma-processing chamber after substrate A has already begun its processing cycle in the same cluster tool. When substrate B enters the plasma-processing chamber, data owner for substrate id collects data indicating that substrate B has entered the processing environment. Meanwhile, the data owner for pressure acquires a multitude of data points because changes in pressure are happening for both substrates. As a result, the absolute timestamp that is recorded on the substrate id table may not match up perfectly with any of the absolute timestamps on the pressure table because the pressure for substrate A is changing at the same time that the pressure for substrate B is beginning to change.
For example, a user is researching a problem with substrate 123. Looking at substrate id table 202, the user is able to determine that substrate 123 entered a plasma-processing chamber at an absolute timestamp 202a of 9:58:09:015. Since the common variable on each of the tables is the absolute timestamp, the user then uses absolute timestamp 202a as a guiding post for retrieving data from the other tables by comparing absolute timestamp 202a against the absolute timestamps on the other tables. In some situations, the user is able to extract the relevant values since absolute timestamp 202a matches the absolute timestamps on the other tables. For example, absolute timestamp 202a matches absolute timestamp 208c on step number table 210.
However, absolute timestamps may not always match on all the tables. Under that situation, the user may have to interpolate based on values corresponding to the absolute timestamps that exist on the tables. For example, absolute timestamp 202a does not match any of the absolute timestamps on pressure table 210. Instead absolute timestamp 202a falls between absolute timestamp 210b and absolute timestamp 210c. Even though the user may be able to determine the range (i.e., actual pressure value falls between 59 and 68 millitorrs), the user may find it difficult to determine an actual value.
There are several problems with the current methods for collecting data from a cluster tool. First, data may not always be readily accessible since the data may be stored locally on a cluster tool or on a network server. To retrieve the data, a user may need to have access to the cluster tool or network server.
Second, data is currently collected on a time slide, grouped by data owners, and is stored on the database as individual tables. For example, data about pressure is stored together on a single table whereas data about gas flow is stored on a different table. To reconstruct processing conditions for a specific substrate may take some time since data for a specific substrate is not readily available.
Third, due to the way data is stored, a user may not be able to automatically request for data without having to do some analysis to determine the usability of the data. Further, since data for a substrate is stored across multiple tables, a user may have to use multiple queries to extract the data needed. Since the common variable among the tables is the absolute timestamp, data that is gathered may not always give an accurate picture of what has occurred since the user may have to synchronize the data on the various tables. As a result, the accuracy and quality of the data may be lacking.